[WIP] CIP draft #396
[WIP] CIP draft #396
Conversation
There was a problem hiding this comment.
thanks @will-break-it for inviting review from the CIP community. I've also read through the rest of the text in the same branch and it looks like it will be well in order for posting as a CIP pull request as soon as the bulk of TODO items are completed.
docs/cip/README.md
Outdated
| **Five-Stage Pipeline**: The protocol operates through a structured five-stage pipeline: (1) **Propose** - IBs generated uniformly, (2) **Deliver 1** - IB diffusion using freshest-first strategy, (3) **Deliver 2** - complete IB delivery, (4) **Endorse** - EBs generated at stage start, (5) **Vote** - voting on EBs and certificate creation. This pipeline approach enables concurrent transaction processing while maintaining deterministic ordering and conflict resolution. | ||
|
|
||
| **Input Blocks (IBs)**: Transaction-containing blocks produced at a uniform rate during the "Propose" stage of each [pipeline](#pipeline). IBs are generated by stake pools that win VRF-based [sortition](#sortition), with the protocol utilizing approximately one-third of available network bandwidth for IB traffic. Multiple IBs can be produced concurrently across the network. | ||
|
|
||
| **Endorser Blocks (EBs)**: Aggregation blocks that reference multiple IBs from the current pipeline. EBs are produced at the beginning of the "Endorse" stage by selected stake pools. An EB represents a consensus view of which IBs should be included in the permanent ledger, referencing all IBs that were delivered by specific pipeline deadlines. | ||
|
|
||
| **Votes and Certificates**: During the "Vote" stage, stake pools [vote](#vote) on EBs if they meet strict criteria: all referenced IBs must be available, all IBs seen by the "Deliver 1" deadline must be referenced, and all referenced IBs must validate. When enough votes are collected (achieving a [quorum](#quorum)), a [certificate](#certificate) is created and included in an RB. | ||
|
|
||
| **Ranking Blocks (RBs)**: The main Praos consensus chain blocks that contain at most one certificate per block, attesting to the validity of an EB. RBs anchor the Leios consensus into the established Praos security model and may also contain regular transactions. |
There was a problem hiding this comment.
| **Five-Stage Pipeline**: The protocol operates through a structured five-stage pipeline: (1) **Propose** - IBs generated uniformly, (2) **Deliver 1** - IB diffusion using freshest-first strategy, (3) **Deliver 2** - complete IB delivery, (4) **Endorse** - EBs generated at stage start, (5) **Vote** - voting on EBs and certificate creation. This pipeline approach enables concurrent transaction processing while maintaining deterministic ordering and conflict resolution. | |
| **Input Blocks (IBs)**: Transaction-containing blocks produced at a uniform rate during the "Propose" stage of each [pipeline](#pipeline). IBs are generated by stake pools that win VRF-based [sortition](#sortition), with the protocol utilizing approximately one-third of available network bandwidth for IB traffic. Multiple IBs can be produced concurrently across the network. | |
| **Endorser Blocks (EBs)**: Aggregation blocks that reference multiple IBs from the current pipeline. EBs are produced at the beginning of the "Endorse" stage by selected stake pools. An EB represents a consensus view of which IBs should be included in the permanent ledger, referencing all IBs that were delivered by specific pipeline deadlines. | |
| **Votes and Certificates**: During the "Vote" stage, stake pools [vote](#vote) on EBs if they meet strict criteria: all referenced IBs must be available, all IBs seen by the "Deliver 1" deadline must be referenced, and all referenced IBs must validate. When enough votes are collected (achieving a [quorum](#quorum)), a [certificate](#certificate) is created and included in an RB. | |
| **Ranking Blocks (RBs)**: The main Praos consensus chain blocks that contain at most one certificate per block, attesting to the validity of an EB. RBs anchor the Leios consensus into the established Praos security model and may also contain regular transactions. | |
| ##### Five-Stage Pipeline | |
| The protocol operates through a structured five-stage pipeline: (1) **Propose** - IBs generated uniformly, (2) **Deliver 1** - IB diffusion using freshest-first strategy, (3) **Deliver 2** - complete IB delivery, (4) **Endorse** - EBs generated at stage start, (5) **Vote** - voting on EBs and certificate creation. This pipeline approach enables concurrent transaction processing while maintaining deterministic ordering and conflict resolution. | |
| ##### Input Blocks (IBs) | |
| Transaction-containing blocks produced at a uniform rate during the "Propose" stage of each [pipeline](#pipeline). IBs are generated by stake pools that win VRF-based [sortition](#sortition), with the protocol utilizing approximately one-third of available network bandwidth for IB traffic. Multiple IBs can be produced concurrently across the network. | |
| ##### Endorser Blocks (EBs) | |
| Aggregation blocks that reference multiple IBs from the current pipeline. EBs are produced at the beginning of the "Endorse" stage by selected stake pools. An EB represents a consensus view of which IBs should be included in the permanent ledger, referencing all IBs that were delivered by specific pipeline deadlines. | |
| ##### Votes and Certificates | |
| During the "Vote" stage, stake pools [vote](#vote) on EBs if they meet strict criteria: all referenced IBs must be available, all IBs seen by the "Deliver 1" deadline must be referenced, and all referenced IBs must validate. When enough votes are collected (achieving a [quorum](#quorum)), a [certificate](#certificate) is created and included in an RB. | |
| ##### Ranking Blocks (RBs) | |
| The main Praos consensus chain blocks that contain at most one certificate per block, attesting to the validity of an EB. RBs anchor the Leios consensus into the established Praos security model and may also contain regular transactions. |
The rest of the document currently has no sections for elaboration of these components. Therefore these should have their own headers — rather than inline headings — to make these definitions deep-linkable. I believe making this information accessible is more important than any goal of keeping this information textually dense.
There was a problem hiding this comment.
References
Optional
There is such abundant information here for readers at any level — including development & discussion history for so much of this material — that I would editorially support adding a link here from the Abstract to ensure the reader knows early that it's available... rather than having them wait until the final References section.
ch1bo
force-pushed
the
cip/review
branch
2 times, most recently
from
452236a to
737b8ec
Compare
|
FWIW, I have started to write down more things on this branch and my approval is moot. @will-break-it should we create a new branch / PR for our soon-to-be-more-complete specification section with the phased approach? |
cip: apply review Co-authored-by: Robert Phair <[email protected]>
* docs: add collateralized transaction * docs: fix source links * docs: shorten notes * docs(cddl): remove uneeded block body hash * docs(cddl): remove IB header shard id as it can be derived from the VRF * docs: headline fix * docs(cddl): add sharded reward account * docs(cddl): fix formula * docs(cddl): add collateral tx field for reward accounts * docs(cddl): add more context for sharded reward account * docs(cddl): clarify sharding benefits * docs(cddl): clarify shard assignment for reward account
docs/cip/README.md
Outdated
|
|
||
| In analogy, imagine Praos as a single courier diligently collecting and delivering individual letters one by one, limiting the delivery speed to their individual capacity. Ouroboros Leios, however, operates like a mail sorting office where numerous local branches rapidly collect and bundle letters (input blocks) before a central team efficiently processes and dispatches these aggregated bundles (endorser blocks), achieving a significantly higher delivery volume. | ||
| However, TPS isn't a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS doesn't account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability. |
There was a problem hiding this comment.
300,000 TxB/s
That's probably the upper limit of Linear Leios unless we allow EBs of 15 MB or more.
| network traffic, of course. | ||
|
|
||
| <a name="operating-costs"></a>**Operating costs** | ||
|
|
There was a problem hiding this comment.
| > [!IMPORTANT] | |
| > | |
| > TODO: **@bwbush** | |
| > | |
| > - [ ] Revise this section and the computations to align with Linear Leios |
There was a problem hiding this comment.
I've commented from the start through just before Trade-offs & Limitations.
The motivation and explanation of the modes and linear leios is compelling and clear. 🎉
- Highlighted a few technical concerns about the protocol itself
- Suggested or requested clarification of potentially ambiguous text
- Need to be precise about words like "may", "must", "should", "shall", "can": sometimes these are requirements for honest nodes, sometimes they are constraints on validity, etc. It will be interesting to see how the Agda handles these distinctions.
- Avoid contractions and slang.
- I didn't see any big gaps other than what is already in progress (incentives, mini-protocols).
* docs(cip): refactor specification for L_recover without modes
| | Characteristic | Symbol | Units | Description | Typical Range | Notes | | ||
| | ------------------------- | :-----------------: | :---: | ----------------------------------------------------------- | :-----------------------------: | -------------------------------------------------- | | ||
| | RB diffusion time | $\Delta_\text{RB}$ | slot | Observed upper bound for RB diffusion and adoption to all nodes | 2-6 slots | Depends on network topology and conditions | | ||
| | RB header diffusion time | $\Delta_\text{hdr}$ | slot | Observed time for RB headers to reach all nodes | $\leq \Delta_\text{RB}$ | Usually faster than full block diffusion | |
There was a problem hiding this comment.
This is an observed property of the network, but EB equivocation protection requires nodes to wait
There was a problem hiding this comment.
Mh interesting take, I've noted this remark. Let's take another look at it in our weekly.
TODO: Weekly review
There was a problem hiding this comment.
Isn't it implicitly given by L_vote to be greater than
|
|
||
| </div> | ||
|
|
||
| <a id="protocol-parameters" href="#protocol-parameters"></a>**Protocol Parameters** |
There was a problem hiding this comment.
I remember in Edinburgh, someone mentioned that there had to be a way to gracefully enable and disable Leios. Do we need some protocol parameter for that? (is setting
There was a problem hiding this comment.
TODO: Weekly review
|
|
||
| </div> | ||
|
|
||
| <a id="protocol-parameters" href="#protocol-parameters"></a>**Protocol Parameters** |
There was a problem hiding this comment.
How are memory/CPU execution constrained? Praos has a "maxBlockExecutionUnits" parameter, but we're expecting to include many more TXs in EBs than Praos could; do we need a dedicated "maxEndorserBlockExecutionUnits" parameter?
There was a problem hiding this comment.
TODO: Weekly review
|
|
||
| #### Transaction Diffusion | ||
|
|
||
| <a id="transaction-propagation" href="#transaction-propagation"></a>**Transaction Propagation**: Uses the TxSubmission mini-protocol exactly as implemented in Praos. Transactions flow from downstream to upstream nodes through diffusion, where they are validated against the current ledger state before being added to local mempools. The protocol maintains the same FIFO ordering and duplicate detection mechanisms. |
There was a problem hiding this comment.
I don't think TX propagation works exactly the same as in Praos. Nodes must propagate any transactions which belong to an EB, even if their mempools are full or contain conflicting TXs.
There was a problem hiding this comment.
After reading further: I think that the "Transaction Retrieval" section implies that the TxSubmission protocol works exactly the same way it does today, but in addition there's another set of TX miniprotocols which don't interact with the mempool. Is that the case? If so, might be worth mentioning that section here.
docs/cip/README.md
Outdated
|
|
||
| #### RB Block Production and Diffusion | ||
|
|
||
| When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection. |
There was a problem hiding this comment.
| When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection. | |
| When a stake pool wins block leadership (step 1), they simultaneously create two things: a ranking block (RB) and an endorser block (EB). The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection. |
if you're (re)introducing concepts here, I think it's a good idea to (re)define the acronyms
|
|
||
| <a id="VotingEB" href="#VotingEB"></a>**Voting Process**: Committee members [selected through a lottery process](#votes-and-certificates) vote on EBs as soon as vote requirements are met according to protocol (step 9). An honest node casts only one vote for the EB extending its current longest chain. |
There was a problem hiding this comment.
The rust simulation handles voting in Linear Leios the same way as in every other variant; pools with sufficiently high stake can win multiple voting opportunities from a VRF lottery, and if they do then they produce multiple votes in favor of that EB.
Does "An honest node casts only one vote for the EB extending its current longest chain" imply that this voting strategy is incorrect, and that every pool produces at most one unweighted vote for an EB?
docs/cip/README.md
Outdated
|
|
||
| ### Specification for votes and certificates | ||
| <a id="certificate-inclusion" href="#certificate-inclusion"></a>**Certificate Inclusion**: Block producers creating new RBs include certificates for EBs where the full stage duration ($L_\text{vote}$ slots) has elapsed since the EB's creation (step 12). The producer may also announce a new EB extending their RB. Including a certificate resets the $L_\text{recover}$ rolling window, either extending an existing enhanced throughput period or starting a new one (as detailed in [Rolling Window Rules](#rolling-window-rules)). |
There was a problem hiding this comment.
I thought we got rid of this
Rendered Version